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Introduction 



Purpose of This Publication 

The purpose of this pubHcation is to describe the capa- 
bihties of the Random-Processing Scheduler, and the 
function and use of the macro-instructions and dtf 
(Define the File) and da (Define Area) statements 
needed to utilize the capabilities of the Scheduler in 
random processing applications involving the use of 
IBM 1301 Disk Storage. 

Purpose of the Random-Processing Scheduler 

The Random-Processing Scheduler is an optional com- 
ponent of the IBM 1410/7010 Operating System, pro- 
viding facilities for eflRcient handling of input/output 
operations involving random access devices. 

The goal of the Random-Processing Scheduler is to 
permit a random processing program to be planned 
as if using a serial "read a record, process it, write it" 
procedure. Actual execution of the program, however, 
is controlled by the Random-Processing Scheduler 
(hereafter called the Scheduler). The order in which 
records will be processed is determined by the Sched- 
uler so that maximum operating efEiciency is obtained. 

The Random-Processing Scheduler is designed to be 
of maximum value for applications involving the up- 
dating of files resident in disk storage, where the data 
to be used in updating these files is not batched by 
type or sorted beforehand. The advantages of the 
Scheduler are lost if it is used in a sequential process- 
ing application. 

By providing routines for the supervision and con- 
current scheduling of input/output operations in a ran- 
dom processing application, the Scheduler relieves the 
user of the major programming task of designing an 



efficient random processing input/output control sys- 
tem. 

Machine and Operating System Requirements 

The machine requirements for assembling source pro- 
grams written in the Autocoder language are specified 
in the pubhcation, IBM 1410/7010 Operating System; 
System Generation, Form C28-0352. The machine re- 
quirements for execution of the object program depend 
upon the combined requisites of the System Monitor 
and the user's program. 

The Random-Processing Scheduler requires of the 
Operating System that its Resident Monitor be condi- 
tioned to handle interrupt exits and 1301 Disk Storage. 
This is accomplished during generation of the Operat- 
ing System by entries in the Resident iocs Definitions 
macro-statements. 

Prerequisites 

It is assumed that the reader of this publication is 
familiar with fundamentals of programming the ibm 
1410 or 7010 Data Processing System. To successfully 
prepare programs utilizing the Scheduler, the reader 
should also be familiar with the following publications: 

IBM 1410/7010 Operating System; Basic Concepts, 
Form C28-0318 

IBM 1410/7010 Operating System; System Monitor, 
Form C28-0319 

IBM 1410/7010 Operating System; Autocoder, Form 
C28-0326 

IBM 1410/7010 Operating System; Basic Input/Out- 
put Control System, Form C28-0322 
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Random Processing Concepts 



Random access devices make it possible to directly 
pick out wanted data from a file, in a sequence estab- 
lished by the program using the data, not by the data 
arrangement. Also present is the capability of accessing 
data from a number of files in a sequence dictated by 
program need, not by file arrangement. In contrast, 
sequential access devices, such as magnetic tape, make 
data available only in a fixed, serial order. 



Handling Disk Data 

The arrangement of data and program requirements 
determine the method used in moving information to 
and from disk storage. Three methods of moving disk 
data are in general use and are known as single-record, 
sequential, and random processing. 

Single-Record Processing 

Single-record processing is defined as obtaining disk 
records of any format, brought from any area of disk 
storage, in any arbitrary order of addresses. It is the 
most flexible method of moving data to and from disk 
storage. The primary use of this method is in applica- 
tions where the precise nature and the location of the 
data to be moved are not known at the time the pro- 
gram is written. 

Sequential Processing 

Sequential processing is defined as obtaining disk 
records in the order of ascending addresses. When in- 
formation is transferred sequentially there is virtually 
no seek time involved if the records are arranged cor- 
rectly on disk. Therefore, it is the fastest method of 
moving large amounts of data to and from disk storage. 
In many respects sequential processing is similar to 
tape processing, and, because of this, is not suitable 
for applications requiring arbitrary, or random, re- 
trieval of disk data. 

Random Processing 

Random processing is defined as obtaining disk rec- 
ords of uniform format, belonging to specific files, in 
any arbitrary order of addresses. It is the most widely 
used method of reading and writing disk data and 
lends itself to any application where data in a specific 
file must be processed in an arbitrary order. The Ran- 
dom-Processing Scheduler is designed to implement 
this type of operation. The next section expands on 
this concept. 



Random Reference Processing 

Use of the random processing method generally as- 
sumes that the input data ( transaction records ) comes 
from a source other than disk storage, although a se- 
quential disk file might be used for input. It also as- 
sumes that the transaction data is to be processed 
against data obtained from a disk file. The processing 
creates updated or new data to be placed back in disk 
storage or used as output to other input/output de- 
vices. Each transaction record contains the identifica- 
tion for one or more items in disk storage that are to 
be processed against the transaction data. 

Separation of Routines 

When a transaction record becomes available, the 
process of issuing Seeks and Reads for one or more 
disk records must be performed. To utilize this time 
it is convenient to divide the total processing of an 
item into smaller routines, which will be referred to 
as the main routine and the disk routine. 

The main routine is used to obtain transaction rec- 
ords and place them in an area of storage available to 
the disk routine. If the user desires, the main routine 
may include other operations that do not require data 
to be obtained by the disk routines. 

Control is passed by the main routine to the disk 
routine after a transaction record has been made 
available by the main routine, and the disk routine 
proceeds to obtain the disk record needed, process it 
against the transaction record, and prepare the result 
for placement back into disk storage and/or as output 
data for some other input/output device. Because of 
the time required for disk functions, i.e.. Seek and 
Read, between the execution of a main routine and the 
ability of the disk routine to process a record, a void 
exists during which no instructions referring to the 
data may be executed. Random processing schemes 
utilize this time to read in more transaction records or, 
if possible, initiate execution of another disk routine 
for which data is available in core storage. Thus, in 
addition to keeping the computer busy, new requests 
for disk data are being generated continually so that 
access mechanisms are being utilized to the fullest 
extent with overlapped Seek operations. 

If the user requires the output from a program to 
be in the same sequence as the transaction records 
that are brought in, an option is provided whereby the 
user may force the execution of disk routines in the 
same order as the transaction records are brought into 
the computer. 
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Relationship to the Operating System 

The Scheduler consists of routines that are incorpo- 
rated into the using program by means of the Linkage 
Loader. The Scheduler routines are not contained in 
the Resident iocs. The Scheduler routines are placed 
in relocatable format on a library file, which, when 
the routines are to be incorporated in a program, must 
be assigned as the System Library file. Information 
concerning the placement of Scheduler routines on 
the library file, and assignment of a System Library 
file, is contained in the publications, IBM 1410/7010 
Operating System; System Generation, Form C28-0352, 
and IBM 1410/7010 Operating System; System Moni- 
tor, Form C28-0319, respectively. In brief, the assembly 
of a program utilizing the Scheduler routines takes 
the following steps: 

1. The output of the Autocoder processor is one 
or more subprograms in relocatable format, contain- 
ing imbedded calls for appropriate Scheduler routines. 
The calls are generated when the Autocoder processor 
encounters a Scheduler macro-instruction. 

2. The subprograms are then processed into abso- 
lute format by the Linkage Loader, which gathers the 
calls for Scheduler routines, obtains the routines from 
the Library, and processes them into absolute format 
with linkage to the using program. The program, with 
Scheduler routines, is now in absolute format on the 
Job file. 

The Scheduler imposes no requirements for control 
information beyond those stated in the System Moni- 
tor and Autocoder publications for assembly and 
execution of a program. 

Note: Programs servicing a tele-processing® Sys- 
tem may be utilizing Scheduler routines and may be 
resident in core storage at the same time as a main- 
line program using the Scheduler. The result of this 
is the presence in storage of two sets of Scheduler 
routines. The Scheduler routines must not be in- 
corporated in the Resident Monitor. 



Relationship to the Basic Input/Output Control System 

The Scheduler extends the Basic Input/Output Control 
System ( iocs ) component of the Operating System by 
providing routines for handling disk data in a random 
processing application. These routines, combined with 
IOCS operations, will efficiently handle the input/output 
requirements of any random processing application. 



For example, in obtaining information from disk stor- 
age, the Scheduler determines whether or not a Seek 
operation is required, and in which input/output area 
the information is to be placed. Control is then passed 
to the IOCS to perform the actual input/output opera- 
tions of seeking (if needed), reading the record, and 
handling error situations if they arise. In brief, the 
Scheduler routines combined with the iocs will auto- 
matically: 

Schedule the maximum number of Seek, Read, 
and Write operations for efficient operation 

Overlap disk input/output operations with proc- 
essing 

Perform the actual Seek, Read, and Write opera- 
tions 

Check for read and write errors 

Correct all correctable read and write errors 



Capabilities of the Scheduler 

Retention of Transaction Records 

Successive transaction records are stored in a Transac- 
tion Stacking Area until they can be processed. If the 
Stacking Area is full, the Scheduler delays reading in 
any more transaction records until room is available. 
During this delay, disk records will be processed as 
they become available. The processing of a disk record 
takes precedence over reading another transaction 
record. Control is passed back to the main routine 
only if no disk record is available for processing and 
the Scheduler is able to accept more transaction rec- 
ords. ( If two transaction records request the same disk 
record, the Scheduler does not process the second re- 
quest until the first has been completed. ) The Sched- 
uler retains transaction records until notification that 
all disk routines needing the record have been satisfied. 

Holding Disk Records 

The records obtained by the read operations in the 
disk routines are held in the input/output area desig- 
nated for that file until they are no longer required. 

Correlation of Disk Records with Transaction Records 

As described in the "Random Processing Concepts" 
section, the separation of routines permits concurrent 
handling of several input/output operations. Each time 



The Random-Processing Scheduler 7 



a disk record is successfully sought and read, it is made 
ready for processing. The Scheduler ensures that, 
whenever control is passed to a disk routine for proc- 
essing a record, data from the correct transaction rec- 
ord is used. 

Release of Transaction Stacking Areas 
and input/Output Areas 

The Scheduler ensures that no areas are released to 
receive new data until all routines needing their pres- 
ent contents are satisfied. 



Main Routine 



Disk Routine 



The Random-Processing Scheduler 
Macro-Instructions 

The following is a brief description of each of the 
three macro-instructions used in coding a program 
utilizing the Scheduler facilities. Refer also to Figure 
1, which shows graphically the placement of the in- 
structions within a random processing scheme. 

GET — Get Disk Record 

This macro-instruction is used to seek (if necessary) 

and READ disk records. 

PUT — Put Disk Record 

This macro-instruction is used to seek (if necessary) 

and write disk records. 

lOCTL xxxxx — Input/Output Control 
This macro-instruction can direct the Random-Process- 
ing Scheduler to perform a specific function as de- 
termined by the first operand (called the directing 
operand). Since the ioctl operation cannot be used 
without the directing operand, the two will be referred 
to together as a form of the macro-instruction. The 
following are the forms of the macro-instruction, with 
a description of each. 




to A or B 



Fif^ure 1. Macro-Instructions for Random Processing 



lOCTL FSEQP — Force Sequential Processing. 

This form of the macro-instruction is used to en- 
sure that records are processed in the order in 
which transaction records were received, regard- 
less of the order in which the disk records were 
accessed. It is not shown in Figure 1. 

lOCTL MVRSA — Movc Rccord to Stacking Area. 
This form of the macro-instruction is used to move 
transaction records to the Transaction Stacking 
Area. 

locTL OPEN — open Disk Files. 

This form of the macro-instruction is used to open 
disk files used for random processing. 
lOCTL CLOSE — Close Disk Files. 

This form of the macro-instruction is used to close 
disk files used for random processing. 
lOCTL ENTRND — Enter Disk Routine. 

This form of the macro-instruction must be used 
to define the beginning of any disk routine. 
lOCTL LEAVE — Lcavc Disk Routine. 

This form of the macro-instruction must be used 
to define the end of any disk routine. 
lOCTL STACK — Open Stacking Area. 

This form of the macro-instruction is used to es- 
tablish linkage between the Transaction Stacking 
Area and the Scheduler. (Do not confuse this 
macro-instruction with the unctl stack macro- 
instruction for basic iocs.) 
lOCTL DEFSA — Define Stacking Area. 

This form of the macro-instruction is used to de- 
fine a field in storage as a temporary Transaction 
Stacking Area. 
Random files named in the operand field of a Sched- 
uler macro-instruction must be defined by a dtp (De- 
fine the File ) statement, written as described in the 
following section of this publication. Further, files 
other than the files to he handled as random files must 
be defined by dtf statements as specified in the publi- 
cation., Basic Input/Output Control System, and the 
basic IOCS forms of the macro-instructions are used 
with them. For example, the transaction record file 
and its associated get macro-instruction would be de- 
fined and used as detailed in the Basic Input/Output 
Control System publication. The open and close func- 
tions for the transaction record file would utilize basic 
IOCS routines also. 



As shown in Figure 1, the ioctl open macro-instruc- 
tion is mandatory for each file, and directs the Sched- 
uler to establish linkage with each file named in the 
operand. This macro-instruction also identifies a file as 
a RANDiN or RANDOUT file. (For definition of these terms 
see the put macro-instruction discussion in the next 
section of this publication.) 

The IOCTL STACK macro-instruction establishes link- 
age between a Transaction Stacking Area and the 
Scheduler before the area is used by the program. This 
area is available to both the main routine and the disk 
routine and must be defined by a da (Define Area) 
statement. (See the next section for details.) 

The IOCTL MVRSA macro-instruction is used to place 
data (i.e., transaction records or data developed by the 
main routine) into a Transaction Stacking Area. It has 
three formats and will either: (1) move data from an 
input area to a segment of the Transaction Stacking 
Area; (2) select a segment of the Transaction Stacking 
Area, leaving the selection and movement of data to 
the user; or (3) will move data from an input area to 
one of several Transaction Stacking Areas. 

The IOCTL ENTRND macro-iustructiou must be used 
as the first entry in a disk routine. It stores the return 
address to the main routine. 

The GET macro-instruction makes a random file rec- 
ord available for processing. The user must develop 
the address needed to obtain the record. 

The PUT macro-instruction is used to place processed 
records on a disk file, and will either place a record 
back in the location from which it was obtained, or 
place it in a location designated by the user. 

The IOCTL LEAVE macro-instruction must be the last 
instruction used in a disk routine. It handles the re- 
lease of the input/output and Transaction Stacking 
Areas used by the disk routine with which it is asso- 
ciated. The LEAVE macro-instruction also performs 
checking functions, which are detailed in the next 
section. 

The IOCTL DEFSA macro-instruction is closely related 
to the MVRSA instruction. It allows the Scheduler to 
treat the location of any data in storage as a segment 
of a Transaction Stacking Area. The user must provide 
a routine to release this temporary transaction area. 

The IOCTL FSEQP macro-instruction is not shown in 
Figure 1. Details of its operation are discussed in the 
next section. 
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Sepmation of Processing Routines 

The operating principles of the Scheduler are illus- 
trated in Figure 2 and discussed in Table I. Note that 
all instructions needed to obtain or process disk data 
have been removed from the main routine. Transac- 
tion records are stored in a special area (Transaction 
Stacking Area ) to await processing. 

Separating the disk routine(s) from the main rou- 
tine allows the Random-Processing Scheduler to use 
the waiting time to analyze the situation at that point. 
As a result, the Scheduler is able to coordinate the 
maximum possible processing in the disk routine(s). 

Although the main routine initiates processing of 
the disk routine, the two routines are independent of 
one another: the main routine obtains and stores 
transaction records independently of any processing in 
the disk routine, and the disk routine obtains disk 
records and associated transaction records independ- 
ently of processing in the main routine. The Scheduler 
coordinates the transaction record with the correct 
disk record. 



Sequence of Disk Operations 

Although transaction records are stacked in the order 
in which they were obtained by the main routine, up- 
dated disk records are not necessarily read from nor 
written back onto the disk in the same order. This is 
because of the different access times for information 
in disk storage. Information access time depends not 
only on the order in which disk requests are given, but 
also on the location of the requested information in 
disk storage. The Scheduler will schedule all requests 
so that the record that can be obtained first is obtained 
first. 

For example, if the Scheduler receives a request 
which requires an access time of 100 ms, and if before 
this request is honored by the Scheduler, another re 
quest is received that requires the same access mech- 
anism but only requires an access time of 50 ms, the 
last request will be scheduled ahead of the first re- 
quest. In another example, if one access mechanism 
receives a request for information which requires an 
access time of 100 ms, and 10 ms later another access 



Main Routine 

The raain routine obtains a transaction record and requests 
stacking of the record in a segment of the Transaction Stack- 
ing Area. If a segment is available, the record is stacked and 
control is given to the disk routine. If no segment is available 
for the transaction record, processing will be permitted only 
in the disk routine until a segment is released. At this time, 
processing in the main routine will resume. 



Disk Routine 



Processing now continues at Point A (return address of the 
main routine). Main routine processing (if any) is carried out, 
and a branch to the instruction that calls for the reading of 
the next transaction record is taken. This transaction record is 
moved to a free segment of the Transaction Stacking Area and 
control is given to the disk routine at Point B. 



Processing in the disk routine proceeds until a request for a 
GET operation is encountered. The disk routine initiates the 
SEEK and then checks all input/output areas. If a previously 
read disk record is ready for updating, processing continues in 
the disk routine (Point B). If no disk record is ready for proc- 
essing in an input/output area and the Scheduler is able to 
accept additional random requests, control is given to the main 
routine at Point A. 

The waiting disk record is updated with the correct transaction 
data, and the write operation that will write the updated disk 
record back into disk storage is initiated. (As indicated in Fig- 
ure 2, the input/output area that contained the just-updated 
disk record will be released upon completion of the write op- 
eration.) When processing in the disk routine continues, any 
needed report is written, and control of the segment of the 
Transaction Stacking Area that held the correct transaction 
record is returned to the Random-Processing Scheduler. The 
check for an input/output area ready for updating is then made 
again, and control is given to Point A or Point B, depending 
on the outcome of the check. 



Table I. Program Steps Executed by the Random-Processing Scheduler 
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mechanism receives a request which requires access 
time of 50 ms, again the second request will be met 
before the first. In either case, the disk information 
requested last will be obtained before that information 
requested just prior to it. 

If disk records must be processed in the same order 
as the incoming transaction records, processing of the 
data obtained by the second request in the examples 
must be delayed until the data obtained by the first 
request has been processed. This is accomplished by 
the use of the ioctl fseqp ( Force Sequential Process- 
ing) macro-instruction. (See the next section for details 
of the FSEQP macro-instruction. ) 



Independent Disk Routines 

Disk routines are considered independent when the 
processing in one routine is not supported by the 
processing in another disk routine. 

For example, some applications require two (or 
more) independent disk routines. A typical application 
of this type is the updating of a job record and an em- 
ployee record on the basis of one transaction record. 
Both routines use the same Transaction Stacking Area. 
However, each routine operates on the transaction rec- 
ord independently, not requiring data developed by 
the other routine ( Figure 3 ) . 

The Scheduler ensures that no segment of the Trans- 
action Stacking Area is released until all disk routines 
requiring data from this segment have been completed. 
The Scheduler can handle any number of independent 
disk routines. 



Dependent Disk Routines 

Some applications use data from one transaction rec- 
ord to update two dependent disk records. Two 
records are considered dependent on one another if 
neither of them can be updated without data from the 
other. When dependent records are processed, both 
disk records must be obtained before either of them 



can be updated. This requires that the disk records be 
retained in their input/output areas until all disk rec- 
ords accessing the related data have been completed. 
The Scheduler can handle any number of dependent 
disk routines. 

Dependent disk routines require the use of the 
IOCTL FSEQP macro-instruction. In Figure 4, the ioctl 
FSEQP macro-instruction in Disk Routine A retains the 
disk record obtained, so that the record is available 
for use by Disk Routine B. The ioctl fseqp macro- 
instruction in Disk Routine B holds up further proc- 
essing in the routine until the disk records requested 
by both routines (A and B) are made available. (For 
a detailed description of the functions of the ioctl 
FSEQP macro-instruction, see the section "Additional 
Functions of the ioctl fseqp Macro-Instruction.") 



Programming Considerations 

The following material is offered as an aid to the pro- 
grammer planning a program utilizing the Scheduler 
facilities. 

1. All random files to be referenced must be de- 
fined by a DTF statement as specified in this manual. 

2. Transaction Stacking Areas and input/output 
areas must be defined by da statements as specified 
in this manual. 

3. The IOCTL MVRSA, IOCTL STACK, IOCTL OPEN, IOCTL 

close, and ioctl defsa macro-instructions are used in 
the main routine. 

4. A get macro-instruction appearing in the main 
routine cannot reference a file that has been defined 
as a random file. 

5. No branching between disk routines may occur. 

6. A disk routine must begin with an ioctl entrnd 
macro-instruction and end with an ioctl leave macro- 
instruction. 

7. Within a disk routine, except for the macro-in- 
structions covered in item 3, all iocs macro-instruc- 
tions may be used. 
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Macro-Instructions, DTF and DA Statements 



This section describes in detail the function and use 
of the macro-instructions and dtf and da statements 
that must be placed in a program making use of the 
facilities of the Random-Processing Scheduler. 



Macro-lnsttuctions 

GET 

The programmer uses the get macro-instruction to 
make a disk record available for processing. 

Before using this macro-instruction for random 
processing, the programmer must store the appropri- 
ate address (single-record or full-track) in an eight- 
character field within the Scheduler. The low-order 
position of this field is represented by the system sym- 
bol, /dk:a/, as shown in Figure 5. 



Channel 


Number 
of Disk 
Unit 


Track or Record Address 


@ or * 

















Figure 5. Location /dka/ 



/i5KA/ 



In either single-record or full-track random proc- 
essing, the user must store in /dka/ the channel desig- 
nation and the number of the disk module as indi- 
cated. The remainder of /dka/ is either the six-charac- 
ter record address of the desired record or the track 
address. 

If the single-record mode is used, the user must 
place the four-digit track address (haI) into another 
field identified by the system symbol /dks/. (This field 
is located within the Scheduler and is a four-character 
field immediately to the left of /dka/. ) The user must 
then place the record address in /dka/. 

In full-track operations /dka/ must contain the four- 
character haI followed by the two-character ha2. 
Since, in full-track operations, there is no record ad- 
dress, the field /dks/ is not used. 

Each time the programmer uses the get macro- 
instruction, the Scheduler, combined with the Basic 
IOCS, will develop the coding required to do the fol- 
lowing. 

1. Check whether another disk operation is using 
the disk track specified by the disk address in the 
/dka/ or /dks/ location. 



2. Assign an available input/output area into which 
the disk record is to be read. 

3. Assign an access mechanism to read the infor- 
mation. 

4. Delay processing on this record if the required 
disk track is being used by another disk operation. 

5. Seek the track specified by the disk address. 

6. Read the disk record into the assigned input/ 
output area. 

7. Check for disk read errors. 

8. Correct the correctable read errors. 

9. Release the input/output area used by a get 
macro-instruction preceding the present get macro- 
instruction. (See the section describing the ioctl 
FSEQP macro-instruction.) 

10. Associate disk records with the appropriate seg- 
ment of the Transaction Stacking Area. 

11. Check whether another disk record is ready for 
processing in an input/output area. 

12. Give control to the appropriate disk routine if 
another disk record is waiting to be processed; or give 
control to the main routine if the Scheduler is able to 
accept additional requests. 

PUT 

The programmer may use the put macro-instruction 
to develop the coding required to include processed or 
unprocessed records in a disk file. 

For the purpose of this discussion, the put macro- 
instructions will be divided into two types: (1) that 
used for input files (to return updated records to disk 
storage), and (2) that used for output files (to load 
information into nonsequential locations in disk stor- 
age). 

Returning Updated Records to Disk Storage: This 
type of PUT macro-instruction is used to return up- 
dated disk records to the locations in disk storage 
from which they were originally obtained. To use this 
type of PUT macro-instruction the file must be opened 
as a random input file. The macro-instruction is writ- 
ten as indicated in Figure 6. 
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Figure 6. The put Macro-Instruction, Type 1 
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The operand in Figure 6 is the name of the disk 
file into which records are to be returned. The name 
must be that used to describe the file in the dtf 
Header Line. 

When using this type of put macro-instruction, the 
programmer must process the disk records in input/ 
output areas. 

Loading Records into Nonsequential Disk-Storage 
Locations: This type of put macro-instruction is used 
to load records into nonsequential locations in disk 
storage. To use this type of put macro-instruction, the 
file must be opened as a random output file. (An 
example of this kind of application is the loading of 
new-parts records into an existing inventory file.) Be- 
fore using this type of put macro-instruction, the pro- 
grammer must: 

1. Place the necessary addressing information in 
the locations /dka/ and /dks/. (See Figure 5 and the 
discussion of addressing in the description of the get 
macro-instruction. ) 

2. Place the information to be written into disk 
storage into the output area that is addressed by the 
index register specified by the dtf index entry of the 
file. 

This type of put macro-instruction is written as 
illustrated in Figure 7. 



lOCTL OPEN 

This macro-instruction is mandatory for each file. It 
directs the Scheduler to establish linkage with the file. 
The operands are: 

OPEN — This operand is the directing operand. 

RANDiN ( or RANDOUT ) — This Operand describes a 
random input (or random output) file. Only one of 
these operands may be present in each ioctl open 
macro-instruction. 

FILENAME — This Operand contains the name of the 
file to be opened. The name must be the same one used 
in the dtf Header Line. There may be one or more 
FILENAME Operands per ioctl open macro-instruction; 
however, input and output files cannot be mixed. 

Figure 8 shows the files named accounts and 
CHRGS being opened as random input files. 
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Figure 8. The ioctl open Macro-Instruction 
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Figure 7. The put Macro-Instruction, Type 2 



The operand in Figure 7 is the name of the disk 
file into which records are to be loaded. The name is 
that used to describe the file in the dtf Header Line. 

Note 1: If an output file is the only random file 
opened, this form of the put macro should not be con- 
tained in a disk routine. 

Note 2: This type of put macro-instruction (with 
an output file named in the operand) cannot be used 
to return an updated disk record to the location in 
which it was originally contained. 

Note 3: This type of put macro-instruction may 
cause the replacement of the entire contents of a disk 
track, according to the record format used. The pro- 
grammer is cautioned against inadvertently destroying 
disk data when using this macro-instruction. (The 
data will be written on disk as specified by the format 
track; therefore, when writing records that are shorter 
than defined by the format track, the remainder of the 
record will be padded with blanks. ) 



IOCTL CLOSE 

This macro-instruction is mandatory for each file. It 
directs the Scheduler to remove the named random 
file from use by the Scheduler. The closing function 
will not take place until the Scheduler has honored 
all requests that were pending at the time the close 
form of the macro-instruction was encountered. The 
operands are: 

close — This is the directing operand. 

RANDIN ( or randout) — This operand describes a 
random input (or random output) file. Only one of 
these operands may be present. 

filename — This operand contains the name of the 
file to be closed. The name must be the same one used 
in the dtf Header Line. There may be one or more 
filename operands per ioctl close macro-instruction; 
however, input and output files cannot be mixed. 

Figure 9 shows the files named newaccnts and 
NVNTRY being closed as random output files. 
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Figure 9. The ioctl close Macro-Instruction 
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lOCTL STACK 

This form of the ioctl macro-instruction is used to 
estabhsh linkage between a Transaction Stacking Area 
and the Scheduler before the area is used by the pro- 
gram. Each Transaction Stacking Area contained 
within the program must be linked to the Scheduler 
by this macro-instruction. The four operands described 
below are required, and must be written in the order 
shown in Figure 10. They are: 

STACK — This is the directing operand. 

LABEL — The second operand is the label of a 
Transaction Stacking Area defined by the user in a 
DA statement. (See the section "da Entries Needed to 
Support the Random-Processing Scheduler.") 

LENGTH — The third operand states the length of a 
segment of this Transaction Stacking Area. All seg- 
ments of any stacking area must be the same length 
and must include a position for a group mark with 
word mark or a record mark. (See the section "da 
Entries Needed to Support the Random-Processing 
Scheduler." ) 

INDEX — This operand specifies the index register 

(XI, X2 X12) to be assigned to this Transaction 

Stacking Area. When the Scheduler returns to the 
user at get+1, the specified index register will con- 
tain the address of the current Transaction Stacking 
Area. If the ioctl stack macro-instruction appears 
several times in a program, the same index register 
must be specified each time. 

Note: Index registers 13, 14 and 15 must not be 
used for this purpose. 

The operand in Figure 10 informs the Scheduler 
that the Transaction Stacking Area labeled trarea 
contains segments of 81 positions (80 data positions 
and 1 position for a group mark with word mark or 
a record mark), and that the user refers to the area 
through index register 8. 
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Fiji;urv! 10. The ioctl stack Macro-Instruction 



IOCTL MVRSA (Move Record \o Stacking Area) 

All data developed by the main routine and required 
by the disk routine(s) must be placed into a Trans- 
action Stacking Area. This ensures that the main rou- 
tine does not alter or destroy the data before it has 
been used by the disk routine(s). 

The programmer may use the ioctl mvrsa macro- 
instruction to transfer data developed in the main 



routine to a segment of the Transaction Stacking Area 
specified by an ioctl stack macro-instruction. 

The data will be retained in the Transaction Stack- 
ing Area until all disk operations using the data have 
been completed. If the Stacking Area is full, the 
Scheduler will wait until processing in a disk routine 
makes a Stacking Area segment available. The iocil 
MVRSA form of the macro-instruction must be given 
in the main routine before control is branched to the 
disk routine. See Figure 11. There are three formats 
of this macro-instruction. 
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Figure 11. Use of the ioctl mvrsa Macro-Instruction 



FORMAT A 

Format A has two operands and is written as indicated 
in Figure 12. The second operand, which may be 
indexed, identifies the high-order position of the area 
from which information is to be moved to the Trans- 
action Stacking Area. Each area from which informa- 
tion is to be removed must have a record mark or a 




Figure 12. The ioctl mvrsa Macro-Instruction, Format A 
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group mark with word mark immediately to the right 
of the low-order position. See Figure 13. 

This format of the ioctl mvrsa macro-instruction 
will cause the Scheduler to: 

1. select an available segment of the Transaction 
Stacking Area specified by an ioctl stack macro-in- 
struction, 

2. insert the address of the selected segment into 
the index register specified by the ioctl stack macro- 
instruction, and 

3. move the information and the word marks con- 
tained in the area specified by the operand into the 
segment of the Transaction Stacking Area selected by 
the Scheduler. 
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B'igure 13. The 80-Character Area Referred to by the Second 
Operand of the ioctl mvrsa Macro-Instruction 



FORMAT B 



Format B of the ioctl mvrsa macro-instruction has 
one operand and is written as indicated in Figure 14. 
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Figure 14. The ioctl mvrsa Macro-Instmction, Format B 

This format of the ioctl mvrsa macro-instruction 
does not move the transaction record, but only selects 
a Transaction Stacking Area segment. The user is 
responsible for moving the transaction record; there- 
fore, the user is afforded the flexibility of moving only 
the portion of the transaction record that contains 
significant information. The user may code the B- 
address of the Move instruction relative to zero and 
index with the index register specified by the ioctl 
stack macro-instruction. 

This format of the ioctl mvrsa macro-instruction 
will direct the Scheduler to: 

1. select an available segment of the Transaction 
Stacking Area specified by the ioctl stack macro- 
instruction, and 

2. insert the address of the selected section of the 
Transaction Stacking Area into the index register 
specified by the ioctl stack macro-instruction. 



format c 

Format C of the ioctl mvrsa macro-instruction has 
three operands. It is written as indicated in Figure 15. 
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Figure 15. The ioctl mvrsa Macro-Instruction, Format C 



This form of the ioctl mvrsa macro-instruction 
directs the storing of data into one of several Trans- 
action Stacking Areas. In this way a program may con- 
tain more than one Transaction Stacking Area that 
must be defined by an ioctl stack macro-instruction. 
The use of these Transaction Stacking Areas is depend- 
ent upon the operands of this format of the ioctl 
mvrsa macro-instruction. 

The first ojperand is the directing operand. 

The second operand identifies the high-order posi- 
tion of the area from which information is to be 
moved to the Transaction Stacking Area. This operand 
may be indexed. 

The third operand identifies the Transaction Stack- 
ing Area into which the transaction record is to be 
stored. This operand is the identifying label of the 
Transaction Stacking Area. (See the section "da 
Entries Needed to Support the Random-Processing 
Scheduler.") 

This format of the ioctl mvrsa macro-instruction 
will cause the Scheduler to: 

1. select an available segment of the Transaction 
Stacking Area designated by the third operand (trarea) 
of this macro-instruction and defined by an ioctl 
stack macro-instruction, 

2. insert the address of the selected segment into 
the index register specified by the ioctl stack macro- 
instruction, and 

3. move the information and the word marks from 
the area specified by the second operand ( infolabel ) 
to the segment of the Transaction Stacking Area speci- 
fied by the Scheduler. 

All Transaction Stacking Areas must be initiated 
with an ioctl stack macro-instruction, and all ioctl 
STACK macro-instructions must refer to the same index 
register. 

IOCTL DEFSA — Define Stacking Area 

This form of the ioctl macro-instruction is very closely 
related to the ioctl mvrsa macro-instruction (Figure 
16). This macro-instruction will allow the Scheduler 
to treat the address of any area in core storage as a 
segment of a Transaction Stacking Area. Whereas the 
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lOCTL MVRSA macro-instruction is used to pick an avail- 
able; segment from a predefined Transaction Stacking 
Area, the ioctl defsa macro-instruction is used to 
handle the area addressed by the index register speci- 
fied in the second operand as a temporary Transaction 
Stacking Area segment. Even though the function of 



the IOCTL MVRSA macro-iustructiou is closely approxi- 
mated, the data in the temporary area is not moved, 
and may not be altered or destroyed until control is 
given to the routine labeled by the third operand. 
The operands are: 

DEFSA — This is the directing operand. 
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Figure 16. The ickitl defsa Macro-Instruction Used in a Random Processing Scheme 
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INDEX — The index register specified should contain 
an address (of an area) which will be associated with 
a disk record as transaction data. The Scheduler saves 
the contents of the index register and restores the 
register when the requested disk record is available. 
The user supplies this address. 

LABEL — This operand must contain the label of the 
user -written closed subroutine to which the Scheduler 
will give control when the temporary Stacking Area 
is ready to be released. At the time this exit is taken, 
the Scheduler will place into the index register speci- 
fied in the second operand the address of the area 
which is no longer required. The closed subroutine 
must not contain any Scheduler macro-instructions or 
any macro-instructions that may require the Scheduler. 

The user-written routine must first store the re-entry 
point to the Scheduler (thus, a closed subroutine), 
perform whatever function is necessary to properly 
release the temporary area, and return to the entry 
point of the Scheduler. 

SPECIAL CONSIDERATIONS 

The Scheduler does not protect areas which are 
stacked by this macro-instruction. If this area is an 
input/ output area, the associated iorw ( Input/Output 
Request Word) should be removed from the file be- 
fore the lOCTL DEFSA macro-instructiou is given. The 
IORW may be returned to the file by the user's closed 
subroutine. 

Figure 17 illustrates a suggested method for han- 
dling a possible situation in which no areas are free 
to be reassigned by the defsa macro-instruction: Test 
for area availability. If no area is free, branch to a 
dummy disk routine which contains only the ioctl 
ENTRND and IOCTL LEAVE macro-iustructions. Upon re- 
turning to the main routine, repeat the test for area 
availability. 



If indexing is used to refer to fields within a tem- 
porary Stacking Area, the index register used must 
be the same one specified in the ioctl defsa macro- 
instruction. 

The ioctl defsa macro-instruction will: 

1. direct that the area addressed by the index reg- 
ister be treated as a Transaction Stacking Area asso- 
ciated with all subsequent random requests until 
another ioctl defsa or ioctl mvrsa macro-instruction 
is encountered, 

2. retain the address of the closed subroutine to be 
entered when the transaction area is no longer re- 
quired, and 

3. restore to the specified index register the data 
placed there by the user (prior to issuing the ioctl 
DEFSA macro-instruction), and enter the release sub- 
routine when the transaction area is ready to be re- 
leased. 

The macro-instruction in Figure 18 will cause the 
Scheduler to treat the area addressed by the contents 
of index register 2 as a segment of the Transaction 
Stacking Area. Control will be given to the routine 
labeled transdone, when the area is no longer re- 
quired. 

Note 1: This macro-instruction must always be given 
in the main line of the program. 

Note 2: The functions performed by the Scheduler 
for the use and release of temporary Stacking Areas are 
based on the assumption that at least two different 
areas will be used by defsa macro-instructions. 




Figure 18. The ioctl defsa Macro-Instruction 
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IOCTL ENTRND 

The ioctl entrnd macro-instruction must be the first 
instruction used in any disk routine of a program 
using the Scheduler. This macro-instruction develops 
the coding required to store the return address of the 
main routine. This is the address to which control will 
be returned by the Scheduler to continue processing 
the main routine. See Figure 19. The user may refer 
to the label of this macro-instruction (Figure 20) in 
branching to his disk routine. 

The coding provided by the ioctl entrnd macro- 
instruction stores the return address of the main rou- 
tine. This permits resumption of processing in the 
main routine as soon as the next disk operation has 
been initiated. 
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Figure l£l. Use of the ioctl entrnd Macro-Instruction 
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Figure 2CI. The ioctl entrnd Macro-Instruction 

IOCTL FSEQP 

The programmer may use the ioctl fseqp macro- 
instruction to ensure that disk records obtained by the 
disk routine ( s ) will be processed and returned to disk 
storage in the same order in which the corresponding 
transaction records were obtained by the main rou- 
tine ( Figure 21 ) . 

For example: Assume that Module 1 receives a 
request for information with an access time of 100 
ms, and that 10 ms later Module 2 receives a request 
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with an access time of 50 ms. In this case, the access 
mechanism of Module 2 will obtain the specified in- 
formation before the access mechanism of Module 1. 

If the disk routine does not use the ioctl fseqp 
macro-instruction, the information obtained by the 
access mechanism of Module 2 will be processed and 
the result returned to disk storage before the informa- 
tion sought by the access mechanism of Module 1 can 
be read. In this case, the updated information will not 
be returned to disk storage in the order in which the 
corresponding transaction records were read by the 
main routine. 

If the disk routine in the example uses the ioctl 
FSEQP macro-instruction, the information obtained by 
the access mechanism of Module 2 will not be proc- 
essed until the information obtained by the access 
mechanism of Module 1 has been processed. 

The IOCTL FSEQP macro-instruction has one operand, 
and is written as indicated in Figure 22. It may be 
used anywhere in the program. 
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Figure 22. The ioctl, fseqp Macro-Instruction 

Each time the programmer inserts an ioctl fseqp 
macro-instruction in his program, the Scheduler will 
develop the coding required to: 

1. delay the processing of the disk record until all 
previously requested records have been processed, 

2. branch control to the appropriate disk routine if 
another disk record is waiting to be processed, or 

3. branch control to the main routine if the Sched- 
uler is able to accept additional requests, or 

4. branch control to a waiting loop if a disk record 
cannot be processed and if the Scheduler cannot ac- 
cept additional random requests (Figure 23). 
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Figure 21. Use of the ioctl fseqp Macro-Instruction 
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If the lOCTL FSEQP macro-instruction is given in the 
main routine, processing in the main routine will not 
continue until all random disk storage data has been 
processed. 

ADDITIONAL FUNCTIONS OF THE lOCTL FSEQP MACRO- 
INSTRUCTION 

The lOCTL FSEQP macro-instruction has two important 
additional functions. It can be used to prevent: 

1. the release of an input/output area by the sec- 
ond of two successive get macro-instructions, for dif- 
ferent files, or 

2. the release of an input/output area by an ioctl 
LEAVE macro-instruction. 

retention of disk data AFTER SECOND GET MACRO- 
INSTRUCTION 

Each time two disk get macro-instructions follow one 
another in a program, the second get macro-instruc- 
tion causes the release of the information obtained by 
the first GET macro-instruction. Thus, the coding se- 
quence 

GET DISKFILeI 
GET DISKFILe2 
PROCESS 

I'UT diskfile2 
will cause the release of the information obtained by 
the first GET macro-instruction, and only the informa- 
tion obtained by the second get macro-instruction 
can be returned to disk storage by a put macro-in- 
struction. The ioctl fseqp macro-instruction may be 
used to prevent the first get macro-instruction, as indi- 
cated by the following coding sequence: 

GET DISKFILEI 
ioctl FSEQP 
GET DISKFILe2 
I'ROCESS 

PUT diskfile2 

PUT diskfileI 
In this case, the ioctl fseqp macro-instruction pre- 
vents the release of the information obtained by the 
first GET macro-instruction. 

The order of the put macro-instructions should be 
given as indicated, since the access mechanism is al- 
ready positioned at the track that contained the data 
from diskfile2. 

The ioctl fseqp macro-instruction cannot be used 
to hold information obtained by the first of two get 
macro-instructions involving the same file. Thus, in 
the coding sequence 

GET diskfileI 

IOCTL FSEQP 

GET diskfileI 

PROCESS 



the IOCTL FSEQP macro-instruction cannot prevent the 
release of the information obtained by the first get 
macro-instruction. 

RETENTION OF DISK DATA AFTER THE IOCTL LEAVE 
MACRO -INSTRUCTION 

The IOCTL LEAVE macro-instruction, described next, 
releases the information obtained by the get macro- 
instruction ( s ) in the disk routine. 
Thus the coding sequence 

GET diskfileI 

process 

ioctl leave 
will cause the release of the information obtained by 
the GET macro-instruction. The ioctl fseqp macro- 
instruction may be used to prevent the release of disk- 
record information by the ioctl leave macro-instruc- 
tion. Thus, in the coding sequence 

GET diskfileI 

IOCTL fseqp 

ioctl leave 
the information obtained by the get macro-instruc- 
tion will be retained in an input/output area for 
processing by a subsequent disk routine (Figure 4). 

Note 1: An ioctl fseqp macro-instruction may re- 
quire the Scheduler to reread a disk record; there- 
fore, the contents of an input/output area must not 
be changed between the get macro-instruction and the 
IOCTL fseqp macro-instruction. The coding sequence: 

GET diskfileI 

update 

IOCTL fseqp 
might result in rereading a disk record and overlaying 
the previous updating of the same record. 



IOCTL LEAVE — Leave Disk Routine 

The IOCTL LEAVE macro-instruction (Figure 24) must 
be the last instruction in a disk routine of a program 
using the Scheduler. Each time processing of a set of 
transaction data has been completed by the disk rou- 
tine, the input/output areas used by the data must 
be released, and control must be returned to another 
disk routine or to the main routine. This macro- 
instruction directs the Scheduler to develop all the 
coding required to handle these functions ( Figure 25 ) . 
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Figure 24. The ioctl leave Macro-Instruction 
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Figure 25. Use of the iocti, leave Macro -Instruction 



What This Macro-Instruction Will Do: Each time 
the programmer uses the ioctl leave macro-instruc- 
tion, the Scheduler will develop the coding required 
to: 

1. check whether the data in the current segment 
of the Transaction Stacking Area is required by an- 
other disk routine, if any, 

2. free the segment of the Transaction Stacking 
Area used by a completely processed transaction rec- 
ord, 

3. send control to the subroutine defined in an 
IOCTL DEFSA macro-iustructiou, if this macro-instruc- 
tion was used to define the transaction record to be 
released, 

4. release the input/output area used by the get 
macro-instruction immediately preceding the present 
IOCTL LEAVE macro-iustruction ( see the section describ- 
ing the IOCTL FSEQP macro-instruction), 

5. check whether another disk record is ready for 
processing in an input/output area, 

6. branch control to the appropriate disk routine 
if another disk record is waiting to be processed, 

7. check whether the Scheduler is saturated with 
requests, and 

8. return control to the main routine if the Sched- 
uler is not saturated with requests. 



The DTF (Define The File) Statement 

Purpose of the DTF Statement 

The programmer who wishes to use the Random- 
Processing Scheduler must write a dtf (Define the 
File ) statement for each disk file used by his program. 



This information consists of up to twelve entries. Each 
DTF statement describes the characteristics of the file 
for which it was written and indicates the methods to 
be used by the Scheduler in handling the file. Using 
the information supplied in the dtf statement, the 
Autocoder processor develops the File Table required 
for the proper handling of each file. 



General Format of the DTF Statement 

The first entry of a dtf statement is the dtf Header 
Line. It consists of the code, dtf, in the operation field 
followed by the name of the file in the operand field. 
All subsequent entries for that dtf statement have 
blank operation fields with the entry name placed in 
the label field. The entries following the header line 
may be listed in any order. 

DTF entries without operands are not permitted. 

All operands of the dtf entries may use address 
modification, where applicable, provided the operand 
consists of no more than 13 characters. Thus, label+110 
is a valid operand if label consists of no more than 
nine characters. All symbolic operands of dtf entries, 
except those of input/output areas, may be indexed. 
(The number of characters used to designate the 
index register must be included in the count of 13. ) 



The DTF Entries 

The following Scheduler dtf entries are described in 
the publication, IBM 1410/7010 Operating System; 
Basic Input/Output Control System, Form C28-0322. 
They may be used with the Scheduler as described in 
that publication, with two exceptions: 

1. The INDEX DTF entry is required for random files. 

2. The STORE operand of the errcheck dtf entry 
must not be used when defining random files. 

errcheck 

filelist 

index 

ioareas 

mode 

order 
The following entries have functions with the 
Scheduler other than those explained in the Basic 
IOCS publication. These other functions are described 
herein. 

SYMUNIT 

erraddr 
erroptns 
filefobm 
The following dtf entry is used only for the Ran- 
dom-Processing Scheduler: 

ACTIVITY 
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ACTIVITY 

The ACTIVITY entry is ordinarily used only with input 
files. (The only time the activity entry is used in 
defining an output file is when that file will be refer- 
enced by a disk routine and will be the only type of 
random file currently open.) 

The activity entry has a single numeric operand, 
which the Scheduler uses to tailor the size of the 
scheduling routine to the user's requirements, so that 
the user will have maximum scheduling efficiency in 
a minimum of core storage. 

The value of the operand may be calculated by de- 
termining the processing time involved in executing 
the main routine and the disk routine through to the 
point where the first get macro-instruction is encoun- 
tered in the disk routine, and dividing this value into 
the average Seek time for the file concerned. The 
result of this division will be a value that can be used 
as the activity operand for the file. This value repre- 
sents the average number of requests for disk records 
that the disk routine may issue before data is made 
available to it from disk storage for processing. 

A number approximating the optimum value for the 
activity oj)erand may be determined by adding one 
(1) to the number of input/ output areas associated 
with the file, i.e., if two input/output areas are as- 
signed to the file, the activity operand would be 
three (3). 

In choosing a value for the activity operand, the 
following points should be considered: 

1. The sum of the activity operands for all files 
represents the maximum number of requests for disk 
records that the Scheduler will be able to accept 
before entering a waiting loop. 

2. The sum of the activity operands for all random 
input files opened must be at least 1. However, if 
the total activity defined for the Scheduler is only 1, 
there can be no overlap of input/output with process- 
ing- 

3. When a random input file is only referred to 
following an ioctl fseqp macro-instruction, it does not 
require an activity entry. 

4. When input/output requests for two or more 
files are mutually exclusive, activity need only be 
specified for one of the files. 

The activity entry is coded as shown in Figure 26. 



ERRADDR 

The ERRADDR DTF entry is used in the same manner 
as described in the publication IBM 1410/7010 Basic 
Input/Output Control System. When using the 
ERRADDR DTF entry for random processing, the speci- 
fied user-written routine must determine which option 
the Scheduler is to take in handling the error situation. 
The user determines the nature of the error by ana- 
lyzing the bit configuration in the error summary 
position of the iorw (18+X15), and specifies one of 
the following options to be taken in handling the error 
(Figure 27): 

1. BXPA /rnr/ — repeat the get or put macro-in- 
struction for that record. 

2. BXPA /RNp/ — process the record anyway. 

3. BXPA /rnb/ — bypass the rest of the disk routine 
(cannot be used with dependent disk routines). 
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Error Routine 
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Position of IORW 
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*'GET 
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IOCTL LEAVE 



»-BXPAANB/— ' 

Figure 27. Directions to the Random-Processing Scheduler for 
Handhng Error Situations, with Eventual Returns 



Note: If it is desired to retry the get with a new 
disk address, the user must place the new address into 
the two eight-position areas preceding the input/out- 
put area associated with the file. (See the "da State- 
ment" section for details of the input/output area.) 
The address of the label will be in the iorw with its 
low-order position at 14-I-X15. Figure 28 illustrates 
placement of addresses. 
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Figure 26. The activity dtf Entry 
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Figure 28. Address Placement 



ERROPTNS 

This entry is optional. It is used when the user desires 
to bypass an independent disk routine if the data 
record it is requesting cannot be obtained without 
uncorrectable errors. If the user desires that the disk 
routine that requested the record be bypassed, then 
an ERROPTNS entry with the bypass operand must be 
included in the dtf statement for the file concerned 
( Figure 29 ) . If an erroptns entry is not included, the 
record with the uncorrectable error will be processed. 
This entry will not handle "no-record-found" condi- 
tions. 

Note: This dtf entry must not be included for files 
that access records for dependent disk routines. If 
the entry were used, a dependent disk routine might 
be bypassed because of an uncorrectable error, but 
the Scheduler would not bypass the additional disk 
routines that follow. 
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Figure 29. The ehroptns dtf Entry 



DA (Define Area) Statements Needed to 
Support the Random-Processing Scheduler 

Some areas required by the Random-Processing Sched- 
uler must be reserved by the programmer by means of 
an appropriate da statement. ( A discussion of da state- 
ments may be found in the Autocoder publication. ) 
All such areas must be terminated by a group mark 
with word mark immediately to the right of the low- 
order position of the area. 



The DA Statement for Input/Output Areas 

Each program utilizing the Random-Processing Sched- 
uler requires at least one input/output area for each 
disk file used by the program. The input/output areas 
are used for storing and processing information ob- 
tained from disk storage. Each input/output area must 
be reserved by the programmer by an appropriate da 
statement. They need not be contiguous in core storage. 
As indicated in Figure 32, each input/output area 
must be preceded by two nine-position areas required 
by the Scheduler. 



FILEFORM 

This entry is required. The operand is fixed and must 
be random, as shown in Figure 30. 
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Figvire 32. Format of an Inpvit/Output Area 
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Figure 30. The fileform dtf Entry 



SYMUNIT (Symbolic Unit) 

This entry is required. It differs from the symunit 
entry used in defining a file to the Basic iocs, in that 
only one operand is used. This operand must be 
"1301." See Figure 31. 
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Figure 31. The symunit Entry 



Figure 33 shows an example of the type of da state- 
ment that must be written for an input/output area 
that will contain a 100-character record, label must 
be the name assigned to this area in the dtf ioareas 
entry. Indexing and referencing to zero may be speci- 
fied in the da entry. The index register specified must 
be the one specified in the index entry of the dtf state- 
ment for the file with which the input/output area 
is associated. 
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Figure 33. da Statement Defining an Input/Output Area 
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The DA Statement for the Transaction Stacking Area 

The DA statement for a Transaction Stacking Area 
is of the form shown in Figure 34. The new entry is 
required by the Scheduler and must be coded as 
shown. The label of the dcw entry is the label used in 
the operands of the ioctl stack and ioctl mvrsa 
macro-instructions. 



Line 
3 5 


Label 

6 15 


Operation 

16 20 


21 25 


30 


35 


40 


0, 1, 


^,N,V,L^.aE,L, , 


D,C,W. . 


0,0,0.0,0. , 








0,2 


1 
. 1 . , 1 1 , , 1 


D,A„ , , 


N.y,M,,,G .,, 1 ,..,,, . 


0,3, 


. . , , . 1 , , , 







|0, 3, I , . I , , . , I 

Figure 34. Coding a Transaction Stacking Area 



The DA entry defines the Transaction Stacking Area. 
N indicates the number of identical segments to 

be reserved. 
M indicates the number of positions to be re- 
served for each segment. (This must include 
a position in each segment for a group mark 
with word mark or for a record mark. ) 
Cx specifies that a group mark with word mark 
is to be included at the end of the entire area 
reserved by this da. 
To simplify the problem of referencing fields within 
segments of the Stacking Area, the da entry may 



specify indexing and referencing to zero. Together, 
these two entries enable the programmer to refer to 
the fields in a segment by name (label). 

If the index register specified is the same as the 
index register defined by the ioctl stack macro-in- 
struction for this Stacking Area, it will be set up and 
maintained by the Scheduler. 

The number of segments, N, in the Transaction 
Stacking Area may be estimated from the following 
formula: 

A 

where : 

A = The sum of the operands of the activity param- 
eters for all files contained within the disk routines 
for which the Transaction Stacking Area applies. 

B = The number of disk routines for which this Trans- 
action Stacking Area applies. Normally, any addi- 
tional segments will waste core storage. 

If variable-length transaction records are to be 
moved into the same Transaction Stacking Area, each 
segment must be large enough to hold the longest 
record. 

Word marks may be specified for segment subfields 
at the user's discretion, e.g., if the programmer desires 
to move data to the Transaction Stacking Area. (See 
Format B of the ioctl mvrsa macro-instruction.) 
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Input/Output Request Word for Random Processing 



The Input/Output Request Words needed by the 
Scheduler are created automatically for the input/ 
output areas defined in the dtf ioareas entry. If addi- 
tional input/ output areas are desired., the programmer 
must construct an iorw, define the additional input/ 
output area and use the label of the first additional 
IORW he constructs as the operand in the filelist dtf 
entry for the file. 

The IORW for the Random-Processing Scheduler is 
slightly different from that for the Basic iocs. There 
are 40 positions in each iorw and these are grouped 
into six fields. Each field is described briefly. Figure 
35 illustrates the coding. 
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Figure 35. Example: Coding of an Input/Output Request Word 



Field 1 is a five-position field. It is not used by the 
Scheduler and may be either zeros or blanks. The low- 
order position of this field is the reference address 
that will be used in handling this iorw. 

Field 2 is a five-position field. It contains the address 
of the List Origin of the File Table for that particular 
file. 

Field 3 is a ten-position field. It will be the appro- 
priate disk instruction that will be executed. 

Field 4 is a ten-position field. It is a conglomerate 
field and the positions are described as follows: 

Position 1 

is always a blank character with a word mark. 

Position 2 

is always a blank character. 



Position 3 

is an error indicator and is coded as a blank. 
When the Scheduler gives control to a user -writ- 
ten error routine, this position will contain a bit 
configuration corresponding to the error condition. 
(See the discussion on the erraddr dtf entry in 
this publication.) 

Position 4 

is either a word separator character, if wrong- 
length-record checking is not desired for this file, 
or a group mark, if wrong-length-record checking 
is desired for this file. There must not be a word 
mark in this position. 

Position 5 
is always a V. 

Position 6 

is always the letter O (11-6 punch). 

Position 7 

is a W, if the erraddr dtf entry is not being used 
for this file, or an O (11-6), if the erraddr dtf 
entry is being used for this file. 

Position 8 
is always a V. 

Position 9 
is always a V. 

Position 10 

is a V, if write disk check is not desired for this 
file, or a W, if write disk check is desired. 

Field 5 is a five-position field and is used by the 
Scheduler. 

Field 6 is a five-position field and is the permanent 
link field. For random processing, it functions just as 
Field 1 functions for the Basic iocs. That is, it must 
contain either the address of the low-order position 
of Field 1 in the next iorw, or zeros if this is the last 

IORW. 

The input/output area to accompany the user-con- 
structed IORW is defined as shown in the preceding 
section. The label of the input/output area must be 
used as the B-address of the instruction coded in Field 
3 of the IORW. 



Input-Output Request Word for Random Processing 27 



Index 



Define Area Statements 

for input/output areas 

for the Transaetion Stacking Area 

Disk routines 

dependent 

independent 

separation of from main routines 10, 

Define the File Statement 23, 

format of 

list of UTF entries 

DTK entries 

ACTIVITY 

ERRADDR 

EKROPTNS 

FILE FORM 

SYMUNIT 

GET macro-instruction 15. 

lOCTL CLOSE macro-instruction 16, 

lOCTL DEFSA macro-instructiou 18, 

locTL ENTRND macio-instruction 20 

locTL FSEQP macro-instruction 21 

loCTL LEAVE macro-instruction 22 

loCTL MVRSA macro-iustruction 17, 

format A 



25 
25 
26 

12 
12 
6 
, 9 
23 
23 

24 
24 
25 
25 
25 
, 8 
, 9 
, 9 
, 9 
, 9 
, 9 
, 9 
17 



format B 18 

format C 18 

loCTL OPEN macro-instruction 16, 9 

locTL STACK macro-instruction 17, 9 

Input/Output Request Word 27 

coding of 27 

Machine Requirements 5 

Macro-instructions for the Scheduler 

definition of 8-9 

illustration 8 

Operating System Requirements 5 

Programming Considerations 12 

PUT macro-instruction 15, 8 

Random Processing 6 

basic principles 6 

Scheduler 

capabilities 7 

principles of the 11 

illustration 10 

purpose of the 5 

relationship to basic iocs 7 

relationship to operating system 7 

Separation of the disk routine from the main routine ... 6, 11 



28 



Reader's Comments 

IBM 1410/7010 Operating System (1410-PR-155) 
Random-Processing Scheduler-1410-IO-967 

Form C28-0323-1 



From 

Name 
Address 



Your comments regarding the completeness, clarity, and accuracy of this publication 
will help us improve future editions. Please check the appropriate items below, add 
your comments, and mail. 

YES NO 

Does this publication meet the needs of you and your staff? 

Is this publication clearly written? 

Is the material properly arranged? ____ ^ 

If the answer to any of these questions is "NO, " be 
sure to elaborate. 

How can we improve this publication? Please answer below. 



I I Suggested Addition (Page , Timing Chart, Drawing, Procedure, etc.) 

I I Suggested Deletion (Page ) 

I I Error (Page ) 



COMMENTS: 



No Postage Necessary if Mailed in U.S.A. 



STAPI.E 



STAPLE 



FOLD 



FOLD 



FIRST CLASS 
PERMIT NO. 81 

POUGHKEEPSIE, N. Y. 



BUSINESS REPLY MAIL 

NO POSTAGE STAMP NECESSARY IF MAILED IN U.S.A. 



POSTAGE WILL BE PAID BY 

IBM CORPORATION 
P.O. BOX 390 
POUGHKEEPSIE, N.Y. 



ATTN : PROGRAMMING SYSTEMS PUBLICATIONS 
DEPARTMENT D9I 



FOLD 



FOLD 



STAPLE 



STAPLE 



C28-0323-1 



s; 



International Business Machines Corporation 

Data Processing Division 

112 East Post Road, White Plains, New York 



